В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:

• CVE-2021-21972 - VMSA-2021-0002 (плагин vRealize Operations Manager)
• CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
• CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)

Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.

В конфигурационный файл на сервере vCenter вам нужно будет добавить одну или несколько следующих строчек, в зависимости от плагина, который вы хотите отключить:

Чтобы отключить сразу все указанные плагины, нужно будет добавить следующий текстовый блок:

<PluginPackage id="com.vmware.vrops.install" status="incompatible"/>

<PluginPackage id="com.vmware.vsphere.client.h5vsan" status="incompatible"/>

<PluginPackage id="com.vmware.vrUi" status="incompatible"/>

<PluginPackage id="com.vmware.vum.client" status="incompatible"/>

<PluginPackage id="com.vmware.h4.vsphere.client" status="incompatible"/>

Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):

Итак, чтобы отключить плагины, вам нужно:

• Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
• Сделать резервную копию файла, например, командой:
  cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
• Открыть этот файл в текстовом редакторе командой:
  vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
• Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):

• Сохранить файл с помощью команды vi:
  :wq!
• Перезапустить сервисы vsphere-ui:
  service-control --stop vsphere-ui
service-control --start vsphere-ui

Если вы все еще используете VMware vCenter for Windows, то указанную процедуру нужно проделать в следующем файле (не забывайте сделать его бэкап):

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

Делается это в том же месте, что и для матрицы совместимости в vCSA:

После этого также перезапускаем службу vsphere-ui для Windows:

C:\Program Files\VMware\vCenter Server\bin> service-control --stop vsphere-ui
C:\Program Files\VMware\vCenter Server\bin> service-control --start vsphere-ui

В том, что плагины отключены вы сможете убедиться в интерфейсе vSphere Client в разделе Administration > Solutions > client-plugins:

Ну и для тех, кому удобнее воспринимать руководство в видеоформате, компания VMware сделала ролик на эту тему:

На днях компания VMware выпустила минорное обновление vCenter 7 Update 2c, которое из нового содержит только багофиксы и исправления в подсистеме безопасности (рекомендуется его накатить в связи с участившимися случаями нахождения и эксплуатации уязвимостей).

Дункан Эппинг рассказал о том, как побороть ошибку, которая иногда возникает при обновлении сервера vCenter на версию vCenter Server 7.0 Update 2c:

Test RPM transaction failed. Collect the logs for diagnostics

Нажатие на кнопку "Resume" ни к чему не приводит, ошибка возникает циклически. Чтобы эту ошибку устранить, нужно удалить файл software_update_state.conf на сервере vCenter Server Appliance. Для этого зайдите туда по SSH и выполните команду:

rm /etc/applmgmt/appliance/software_update_state.conf

Затем перезагружаете виртуальный модуль vCSA командой:

reboot

И снова запускаем установщик:

appliancesh
software-packages install --url --acceptEulas

После этого обновление будет завершено корректно. Скачать VMware vCenter 7 Update 2c можно по этой ссылке.

В начале лета компания VMware выпустила важный документ о сетевой безопасности своей виртуальной среды на базе решения NSX-T, который называется NSX-T Security Reference Guide.

Напомним, что решение VMware NSX-T - это продукт для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker.

Документ NSX-T Security Reference Guide представляет собой основное руководство по безопасному построению виртуального сетевого взаимодействия в рамках датацентра на базе платформы VMware vSphere. Основная цель этого руководства - рассказать пользователям NSX-T о лучших практиках построения защищенной сетевой среды, которая соответствует всем современным требованиям с точки зрения безопасности.

Давайте взглянем на основные главы документа:

• NSX Use cases/Customer journey/ Deployment options
• NSX-T Architecture Components
• Virtual Firewalling
• NSX Firewall Policy Building
• Container Security
• Firewall features
• Intrusion Detection and Prevention
• Federation
• Management and Operations

Документ полностью технический и очень детальный - занимает более 140 страниц, поэтому для всех глубоко интересующихся темой безопасности виртуальных сред на базе vSphere/NSX-T будет очень полезен.

Скачивайте!

Несколько дней назад на различных новостных ресурсах появилась новость о том, что хакерская группа BlackMatter (которая появилась из групп Darkside и REvil) разработала библиотеку esxi_utils, предназначенную для выполнения вредоносных операций с хост-серверами виртуализации VMware ESXi. По-сути, это Linux-шифровальщик, на базе которого строятся программы-вымогатели (Ransomware), наносящие довольно серьезный урон крупным корпорациям.

Злодеи из BlackMatter заявляют своей целью крупные компании (от $100 миллионов годовой выручки), извлеченные данные которых они планируют публиковать в открытом доступе (очевидно, только их часть), а сами данные будут зашифровывать и вымогать деньги. С точки зрения географий - это US, UK, Канада и Австралия.

Итак, на днях группировка выпустила первый Linux Encryptor (Linux ELF64), который использует интерфейс esxcli:

В сам вредоносный пакет включены компоненты, реализующие следующие методы на C:

• esxi_utils
• files_proc
• file_encrypter
• setup_impl
• web_reporter

Будучи внедренными на сервере ESXi, они позволяют выполнять там различные операции, такие как вывод списка виртуальных машин, операции по их выключению, отключение сетевого экрана и многое другое. Это нужно для того, чтобы, например, выключить виртуальные машины перед зашифровкой их дисков.

Также интерфейсы данного средства предусматривают выполнение подобных команд сразу для всей инфраструктуры в один момент времени - то есть на всех серверах все ВМ останавливаются и их диски сразу же шифруются.

Различные источники также пишут, что подобные шифровальщики существуют уже давно и доступны от многих хакерских группировок. Сигнатуры большинства подобных средств уже внесены в базы данных продуктов для защиты корпоративной инфраструктуры.

Возможно, от распространения подобного рода ПО в вашей инфраструктуре вам помогут продукты VMware Carbon Black и VMware AppDefense, а возможно и нет:)

Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

Находим там группу ServiceProviderUsers на второй странице и добавляем туда пользователей, которым мы хотим дать разрешение на просмотр неймспейсов:

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.

Пару лет назад мы писали о модуле VMware NSX Intelligence, который есть в продукте VMware NSX-T. NSX Intelligence - это распределенный аналитический движок, который помогает администраторам более гранулярно контролировать аспекты сетевой защиты на всех уровнях датацентра, упростить проверку инфраструктуры с точки зрения комплаенса и ускорить выполнение процедур обеспечения безопасности.

Одна из возможностей движка NSX Intelligence версии 1.2 - это функциональность Threat Detections, позволяющая своевременно обнаруживать сетевые угрозы и различные аномалии в сетевых коммуникациях. Механизм обнаружения этих угроз построен на базе фреймворка MITRE Enterprise Attack Framework, который учитывает множество аспектов сетевой безопасности крупных предприятий. Об этом немного рассказал Eric Sloof.

Информация об обнаруженных угрозах находится в подразделе Threat Detections раздела Network Traffic Analysis:

На данный момент в режиме технологического превью доступно обнаружение следующих видов аномалий, за которыми может стоять подготовка атак или сами атаки:

• Persistence - Traffic drop - атаки типа отказа в обслуживании (DoS)
• Credential Access - LLMNR/NBT-NS Poisoning and Relay (MITRE ID: T1171) - атаки типа Man-in-the-Middle для перехвата контроля коммуникации между клиентом и сервером
• Discovery - Network Service Scanning (MITRE ID: T1046) - обнаружение хостов, сканирующих порты и сервисы на серверах сети
• Lateral Movement - Remote Services (MITRE ID: T1021) - логин в разные системы под одними кредами
• Lateral Movement - Remote Desktop Protocol (MITRE ID: T1076) - попытки логина на разные хосты по RDP
• Command and Control - Uncommonly Used Ports (MITRE ID: T1509) - попытка системы получить доступ к сервисам через порты, которые обычно не используются

В разделе Event Definitions можно увидеть описание каждого из видов угроз (а их список будет пополняться в будущем) и текущий статус :

Недавно компания VMware объявила о выпуске новой версии средства для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре vRealize Network Insight 6.3 (vRNI + также версия Cloud). Напомним, что о прошлой версии продукта мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном vRNI / Cloud версии 6.3:

1. Поддержка VMware Cloud on Dell EMC

Как и для других облачных и онпремизных инфраструктур, vRNI теперь предоставляет для VMConDellEMC такие возможности, как обнаружение приложений (Application Discovery), планирование миграций, планирование стратегии безопасности, алерты и аналитику, а также детализированные дэшборды вашего окружения.

2. Дэшборд VMware SD-WAN Gateway

Новый дэшборд VMware SD-WAN Gateway показывает производительность и использование шлюзов VMware SD-WAN Edges во всей вашей инфраструктуре SD-WAN.

Для каждого VMware SD-WAN gateway можно посмотреть отдельный дэшборд, как показано на картинке ниже:

Здесь можно увидеть топологию, включающую в себя туннели между VMware SD-WAN Edge и выбранным шлюзом, а также состояния этих туннелей. Для каждого из туннелей можно увидеть метрику Quality of Experience, а также множество других полезных мелочей.

3. Настройка Polling Intervals

Теперь можно настроить периодичность сбора данных со стороны vRNI для компонентов сети, а также сделать сбор данных по запросу. По умолчанию данные собираются каждые 10 минут, но вы можете выбрать и достаточно большой интервал:

Кастомный интервал можно задать и в минутах:

Если вы хотите запустить мгновенный сбор данных прямо сейчас, то вы можете найти опцию Collect Now в разделе Accounts and Data Sources:

4. Функции Network Assurance and Verification

Теперь карту Network Assurance and Verification Network Map можно отобразить на полный экран, что позволяет визуализовать на больших мониторах все компоненты виртуальной и физической инфраструктуры и получить сводную информацию обо всех проблемах и алертах:

Можно убрать лишние элементы и показать "диспетчерский" вид:

 Также в продукте есть Intent library для проверки соответствия конфигураций VRRP и HSRP на active и standby маршрутизаторах:

5. Метрики NSX-T Manager Network Utilization и топ 25 ВМ

Так же, как и Network Utilization Dashboard в разделе VMware Cloud SDDC, теперь в vRNI есть такой же дэшборд и для NSX-T Manager. Network Utilization Dashboard предоставляет детальные метрики, которые включают в себя Network Traffic Rate, а также Packets per Seconds для Tx и Rx, отображаемые в различных форматах:

Также есть вывод списка топ-25 виртуальных машин по значениям метрик network traffic rate и packets per second:

6. Прочие улучшения

• Алерты и тренды для VMware Cloud on AWS configuration maximums (относящиеся к Network и Security)
• Поддержка Platform XL Clusters до 15 узлов
• 40+ событий NSX-T, которые были оптимизированы для near-real-time notification
• Метрики vSAN Datastore

Узнать больше о продукте vRealize Network Insight 6.3 и получить пробную версию можно на этой странице.

Источник.

Компания VMware заявила о доступности решения VMware NSX Advanced Firewall for VMware Cloud on AWS, предназначенного для защиты сетевых соединений организаций, использующий публичное облако VMware Cloud на базе инфраструктуры AWS SDDC (software-defined data center). С помощью этого фаервола администраторы смогут контролировать все коммуникации на уровне 7, используя DPI-техники анализа пакетов на всех виртуальных сетевых адаптерах vNICS виртуальных машин на хостах ESXi виртуального датацентра SDDC.

Используя NSX Advanced Firewall for VMConAWS, вы получите следующие возможности:

• Обнаружение попыток использования эксплоитов и уязвимостей в вашей инфраструктуре
• Защита от уязвимостей на базе гранулярных политик безопасности, работающих на уровне приложений
• Уменьшение поверхности атаки для ваших рабочих нагрузкой за счет регулирования только разрешенного трафика приложений в вашем датацентре
• Бесшовный анализ всего трафика датацентра без единой точки анализа, которая могла бы вызвать падение сетевой производительности
• Возможности для обеспечения соответствия отраслевым стандартам (compliance)

NSX Advanced Firewall можно купить как аддон к вашей инфраструктуре VMware Cloud on AWS. Подробнее об этом фаерволе вы можете прочитать в блоге VMware.

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui

Некоторое время назад мы писали о новой версии решения VMware Cloud Foundation 4.2 (VCF), которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. 

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

Весной этого года мы писали о двух критических ошибках безопасности в сервисах VMware Carbon Black и VMware vCenter - тут и тут, соответственно. В свое время для них были выпущены патчи, закрывающие эти уязвимости. Но, надо сказать, что это далеко не единственные критические моменты в инфраструктуре безопасности vCenter - на днях VMware опубликовала патчи к VMSA-2021-0010 (сообщения CVE-2021-21985 и CVE-2021-21986).

Суть уязвимости заключается в том, что в плагине Virtual SAN Health Check есть дыра в процедуре валидации ввода данных, которая позволяет злоумышленнику получить доступ к удаленному исполнению кода через vSphere Client. CVSSv3 base score этой уязвимости максимальный - 9.8, поэтому нужно обновлять серверы vCenter прямо сейчас.

Если вы не используете VMware vSAN, у вас все равно эта дырка есть, так как плагин vSAN идет вместе с установкой vCenter по умолчанию. Затронуты, кстати, vCenter версий 6.5, 6.7 и 7.0 и их обновления, то есть все самые актуальные на текущий момент. Компания VMware создала по данной уязвимости специальный FAQ.

Если вы не пользователь vSAN, то плагин вы можете просто отключить, но вот если вы используете vSAN для хралищ на базе серверов ESXi, то отключение плагина приведет к невозможности пользоваться консолью управления vSAN.

Также по данной уязвимости на VMware Communities есть специальный трэд.

Итак, теперь, собственно, какие патчи вам надо накатить (полное описание находится здесь):

• Для VMware vCenter 7.0 накатываем vCenter 7.0 Update 2b (вот тут)
• Для vCenrer 6.7 накатываем vCenter 6.7 Update 3n (вот тут)
• Для vCenrer 6.5 накатываем vCenter 6.5 Update 3p (вот тут)

VMware настойчиво рекомендует сделать обновление прямо сейчас, чтобы злоумышленники и всякое ransomware не добавили вам проблем, например, перед летним отпуском:)

Недавно на сайте проекта VMware Labs обновилась утилита App Volumes Entitlement Sync до версии 4.4. Напомним, что она позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать. В прошлый раз мы писали об этом средстве вот тут.

Давайте посмотрим, что нового в Entitlement Sync 4.4 и других версиях, вышедших после 4.1:

• Возможность обработки очень больших JSON-файлов (когда у вас много приложений и пакетов, он получается большой).
• Полностью переработанный механизм сравнения приложений и пакетов с возможностью исправления связей на реплицируемых сайтах
• Предыдущий пункт работает хорошо для формата репликации App Volumes 4.3+, но в целом подходит для любой версии 4.x.
• Поддержка сравнения GUID на основной и резервной площадках в целях индентификации GUID приложений.
• Полностью обновленный механизм логирования - данные записываются в %temp%. Теперь их много, что позволяет лучше проводить траблшутинг процесса.
• Нереплицируемые приложения больше не помечаются как ошибки в консоли.
• Улучшенный механизм постпроцессинга репликации.

Загрузить последнюю версию App Volumes Entitlement Sync можно по этой ссылке.

В начале марта этого года мы писали о серьезной уязвимости в сервисах vCenter (CVE-2021-21972), которая
могла привести к удаленному исполнению кода злоумышленником. Уязвимость по степени критичности оценивалась на 9.8 из 10 (по шкале Common Vulnerability Scoring System Version 3.0). Нашел ее, кстати, русский инженер.

На днях была найдена еще одна уязвимость с высокой критичностью в сервисах Carbon Black - CVE-2021-21982 (вот ее описание на сайте VMware). Она затрагивает виртуальный модуль VMware Carbon Black Cloud Workload версий 1.0.0 и 1.0.1 и приводит к возможности обойти аутентификацию Carbon Black и получить максимальные привилегии (сам модуль находится в онпремизной инфраструктуре). Кстати, уязвимость нашел также русскоговорящий пентестер Егор Димитренко.

Самое забавное, что решение Carbon Black предназначено именно для обнаружения угроз на стороне рабочих станций, их анализа на стороне облака и предпринятия действий по защите инфраструктуры десктопов.

Критичность уязвимости по шкале CVSS - 9.1.

Суть ее заключается в том, что можно изменить URL доступа к административной консоли VMware Carbon Black Cloud Workload appliance таким образом, чтобы получить валидный токен пользователя с максимальными привилегиями к API виртуального модуля. Такой пользователь может просматривать и изменять все настройки модуля.

Чтобы избавиться от уязвимости нужно накатить обновление виртуального модуля VMware Carbon Black Cloud Workload 1.0.2.

Кстати, надо сказать, что в конце марта Егор нашел еще одну уязвимость в сервисах VMware vRealize Operations Manager (CVE-2021-21975 и CVE-2021-21983, на сайте VMware она описана вот тут). Она, правда не столь критична - ее CVSS находится в диапазоне 7.2 - 8.6.

Кстати, чтобы быть в курсе новостей о безопасности VMware можно подписаться на вот этот список рассылки.

На днях в различных источниках появились сообщения об уязвимости CVE-2021-21972, которая есть в сервисах vCenter, что может привести к удаленному исполнению кода злоумышленником. Уязвимость по степени критичности оценивается на 9.8 из 10 (по шкале Common Vulnerability Scoring System Version 3.0) и имеет полное описание на сайте VMware как VMSA-2021-0002.

Интересно, что примеры реализации эксплоитов для Windows и Linux на базе этой уязвимости появились как минимум в шести разных местах, включая репозитории на GitHub (например, тут, тут и тут).

VMware сразу же выпустила патч к этой уязвимости, который вы можете загрузить по этой ссылке.

После публикации уязвимости начались массовые сканирования серверов vCenter (кстати, не удивительно, что уязвимость нашел русский инженер, вот ее описание):

Движок BinaryEdge нашел 15 000 серверов vCenter, торчащих в интернет с этой уязвимостью, а Shodan - около 6 700.

Уязвимость использует дырку в плагине vRealize Operations, который установлен по умолчанию, для неавторизованной загрузки файлов по порту 443, после чего становится доступным удаленное исполнение кода в операционной системе vCenter со всеми вытекающими.

В общем, всем нужно поскорее накатывать патч, так как любой с доступом к порту 443 сервера vCenter может потенциально получить к нему полный доступ.

Уязвимость CVE-2021-21972 затрагивает версии vCenter Server 6.5, 6.7 и 7.01. Соответственно, вам нужно накатить 6.5 Update 3n, 6.7 Update 3l или 7.0 Update 1c как можно скорее. Если накатить сейчас не можете, то временный workaround описан в KB 82374.

На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:

• Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
• Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

• Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
• Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
• Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
• Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
• Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
• Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
• Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.

Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.

Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS. Достаточно большое количество B2C-компаний сталкиваются с необходимостью обработки персональных данных и соответствия требованиям регуляторов. Вариантов много: можно найти подходящий ЦОД и разместиться в колокейшн или выбрать провайдера с необходимым облачным сервисом.

Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.

Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.

Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:

MulNSXT01> set logging-server 192.168.10.8 proto udp level info 
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На узлах Edge Nodes также нужно выполнить такую же команду, зайдя по SSH:

DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:

[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"

Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.

Там это тестовое сообщение можно увидеть в разделе Events:

Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:

Далее в Log Insight можно увидеть это событие, поискав по этому тегу:

Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:

[root@DCA-MulComp01:~] esxcli system syslog config get
   Check Certificate Revocation: false
   Default Network Retry Timeout: 180
   Dropped Log File Rotation Size: 100
   Dropped Log File Rotations: 10
   Enforce SSLCertificates: true
   Local Log Output: /scratch/log
   Local Log Output Is Configured: false
   Local Log Output Is Persistent: true
   Local Logging Default Rotation Size: 1024
   Local Logging Default Rotations: 8
   Log To Unique Subdirectory: false
   Message Queue Drop Mark: 90
   Remote Host: udp://192.168.10.8:514
   Strict X509Compliance: false

На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:

DCA-MulNSXT-ESG01> get logging-servers 
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info

Многие администраторы платформы для сетевой защиты приложений в контейнерах, виртуальных машин и невиртуализованных нагрузок  VMware NSX-T часто сталкиваются с проблемами, связанными с политиками устаревания паролей (password expiration policies), которые заставляют менять пароль локальных аккаунтов к консоли системы:

По умолчанию администратор должен менять пароль каждые 90 дней. Чтобы узнать о текущей политике паролей и сроке действия текущего пароля, надо выполнить следующую команду:

> get user admin password-expiration 

Wed Dec 23 2020 UTC 16:38:51.380

Password expires 90 days after last change. Current password will expire in 90 days.

Чтобы изменить число дней, по прошествии которого пароль устаревает, надо выполнить эту команду:

> set user admin password-expiration 10

Ну и чтобы вовсе отключить устаревание пароля, надо выполнить следующее:

> clear user admin password-expiration

После этого нужно проверить, что политика отключена:

> get user admin password-expiration 

Wed Dec 23 2020 UTC 16:44:56.671

Password expiration not configured for this user

VMware на днях выпустила патч VMSA-2020-0023, который окончательно закрывает уязвимость CVE-2020-3992, имевшуюся в сервисе OpenSLP хоста ESXi. Эта уязвимость типа Use-After-Free позволяла злоумышленнику, имевшему доступ к 427 порту, получить возможность удаленного исполнения кода (эта уязвимость имела критический статус и CVS score 9.8 из 10).

VMware заявляет, что данные патчи, выпущенные 20 октября, не закрывают уязвимость полностью, поэтому нужно скачивать самые последние версии патчей:

Вот сами обновления, которые были выпущены:

• ESXi 7.0 - ESXi70U1a-17119627. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi_7.0.1-0.0.16850804
• ESXi 6.7 - ESXi670-202011301-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi670-202010401-SG
• ESXi 6.5 - ESXi650-202011401-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi650-202010401-SG

Воркэраунд, описанный в статье базы знаний KB 76372, все еще актуален. Его суть заключается в полном отключении сервиса SLP с помощью следующих команд:

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off

Обновляйтесь обязательно!

Пару недель назад компания VMware выпустила обновленную версию решения vRealize Network Insight 6.0 (vRNI), предназначенного для для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений. Напомним, что о версии vRNI 5.3 мы писали вот тут.

Давайте посмотрим, что нового появилось в мажорном релизе vRNI 6.0:

• Функции Network Assurance and Verification (см. картинку выше) для проверки соответствия конфигурации сети поставленным целям:
  • Поддержка Distributed Firewall и Edge Firewall для NSX-T
  • Reachability Intent - проверка связности сети с учетом сетевых политик, заданных администратором
  • Поиск путей с помощью IP-адресов
  • Улучшения масштабирования сетевых карт (Network Map) и улучшенная панель общей информации
  • Поддержка новых дата сорсов - Cisco UCS, ASA и Juniper QFX
• Функции VMware SD-WAN (технология от купленной компании VeloCloud):
  • Отображение схем Edge-to-Edge, Edge-to-Hub, Edge-to-GW Tunnel на дэшборде Edge
  • Отображение сетевых туннелей на дэшборде VeloCloud Edge
  • Поддержка потоков SD-WAN VeloCloud Flows в Flow RTT
  • Новый дэшборд Internet Service Providers (ISP) для идентификации сервис-провайдеров, ассоциированных с сущностями SD-WAN VeloCloud
• Функции публичного облака VMware Cloud on AWS
  • Метрики потоков для TCP RTT и re-transmit
  • Виджет "Top talker" на дэшборде VMC on AWS Direct Connect
  • Расчет метрик потоков в интервале 5 минут
• Улучшения поиска
  • Возможность увидеть объем данных, генерируемых поисковым запросом (только для некоторых запросов)
  • Просмотр списка полезных запросов с их описаниями
• Разделы Pinboards
  • Возможность расшарить pinboards с группами LDAP, Active Directory и пользователями vIDM
  • Сохранение запроса в имени pin вместе с заголовком
  • Сохранения изменений в pin при закреплении его на дэшборде
  • Видимый пинборд "Read Only"
• Функции Backup and Restore
  • Возможность резервного копирования и восстановления данных, таких как SNMP, data source и других настроек. Сюда не включаются данные потоков, метрики сущностей и конфигурации событий
• Поддержка соединения источников данных через прокси
  • Возможность указать веб-прокси для AWS, Azure, VMware Cloud on AWS, SD-WAN, Infoblox и ServiceNow для сбора данных
• Графики метрик
  • Новые графики, которые поддерживают несколько измерений и сущностей, функции zoom-in и другое
• Поддержка vRealize Network Insight Cloud
  • VMware vRealize Network Insight Cloud теперь доступен для VMware Cloud Provider Hub (только в регионе США)
  • VMware vRealize Network Insight Cloud теперь работает для региона Австралия
• Интеграция vRealize Network Insight и VMware HCX (подробнее тут и тут)
  • Поддержка растянутой сети HCX stretched L2 VLAN: функции Flow stitching, маппинг VM to flows
  • Экспорт приложения vRealize Network Insight Application в VMware HCX как Mobility Groups с использованием публичного API и скриптов
• Другое
  • vRealize Suite Lifecycle Manager 8.2 Product Support Pack 1 поддерживает инсталляцию vRealize Network Insight 6.0 (см. тут)

Скачать VMware vRealize Network Insight 6.0 можно по этой ссылке. Release Notes доступны тут.

На прошлой неделе компания VMware выпустила новую версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры VMware vSphere Security Configuration Guide 7 (SCG 7). Теперь документ содержит 78 настроек, так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин.

Что нового появилось в руководстве:

• Совместимость с гайдлайнами по безопасности NIST 800-53, NIST 800-171, CMMC, PCI DSS, ISO 27001, NERC CIP
• Учет аппаратных уязвимостей CPU, таких как Meltdown и Spectre
• Покрытие конфигурациями новых технологий и функциональности платформы vSphere 7

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.

Помимо основного Excel-файла с настройками, в составе скачиваемого архива есть и руководство по применению настроек и работе с ними:

Скачать VMware vSphere Security Configuration Guide 7 одним архивом можно по этой ссылке. Конечно же, документ стоит посмотреть всем специалистам по ИБ, в компетенцию которых входит работа с безопасностью виртуальной инфраструктуры.

На сайте VMware Labs появилась очень нужная многим администраторам вещь - генератор сертификатов VMCA Certificate Generator. С помощью этой утилиты можно получить сертификаты, подписанные центром сертификации VMware Certificate Authority (VMCA) со стороны сервера VMware vCenter / Platform Services Controller (PSC), и использовать их в сервисах VMware или любых других сторонних сервисах.

Это может потребоваться, когда у вас в компании нет собственного Certificate Authority (например, у вас маленький бизнес или своя лаба), чтобы подписывать сертификаты, но, в то же время, вам нужно генерировать сертификаты для ваших служб.

Полученные сертификаты можно использовать для таких продуктов, как vRealize Suite и NSX, а также других из корпоративной линейки VMware. Надо понимать, что если вы доверяете корневому сертификату VMCA, то вы доверяете и всем службам, использующим данные сертификаты.

Срок действия сертификатов вы не можете настраивать, это зависит от версии vCenter. Для vCenter 7.0 вы получите сертификаты сроком действия 2 года.

VMCA Certificate Generator поставляется в виде .jar-файла, который нужно открывать по правой кнопке и выбирать пункт меню "open with jar Launcher", либо надо выполнить следующую команду:

java -jar vmca-cert-generator.jar

Выглядит интерфейс утилиты следующим образом:

Для соединения с vCenter/PSC нужно заполнить данные доступа к серверу и данные сертификата, который необходимо выписать. Далее нужно нажать кнопку "START". Начнется процесс создания сертификата с выводом лога, после чего станет активна кнопка "DOWNLOAD", по нажатию на которую вы получите zip-архив со следующим содержимым:

• certool.cfg - конфиг настроек сертификата
• root.cer - корневой VMCA-сертификат
• Ключи private.key и public.key
• .cer - сертификат в формате X509
• .pfx - зашифрованный сертификат в формате PKCS#12 (пароль для него будет тот, который вы указывали в форме выше)
• chain-with-privkey.pem - цепочка сертификата, включая приватный ключ
• chain-without-privkey.pem - цепочка сертификата без приватного ключа

Разные сервисы требуют сертификаты в различных форматах, поэтому данный комплект очень полезен - вам не нужно будет конвертировать сертификаты.

Для работы генератора вам потребуется среда Java Runtime (протестирована версия 1.8.x) и сервер vCenter 6.7 / 7.0. Скачать VMCA Certificate Generator можно по этой ссылке.

Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.

Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.

Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.

Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:

• Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
• SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
• SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).

Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).

Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.

Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.

Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.

Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).

Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.

В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.

С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.

Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.

Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:

Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.

В октябре прошлого года компания VMware объявила о покупке компании Carbon Black, занимающейся информационной безопасностью на уровне облака (cloud-native endpoint protection platform, EPP). Решение это позволяет обнаруживать угрозы на стороне рабочих станций, анализировать их на стороне облака и предпринимать действия по защите инфраструктуры десктопов предприятия. Это не антивирус, не сетевой экран, а...

На блогах VMware вышла отличная статья про безопасность виртуальных машин и виртуальной инфраструктуры VMware vSphere в целом, расскажем ниже ее основные моменты.

Как известно, одним из действенных способов атак на виртуальную инфраструктуру vSphere является проведение злоумышленником вредоносных действий из виртуальной машины, которая потом уничтожается, часто не оставляя следов и записанных действий. Еще один интересный способ со спецификой виртуализации - украсть виртуальную машину (например, контроллер домена) и ковыряться в ней уже в своей песочнице, чтобы вытащить нужную информацию.

Для предотвращения подобных типов угроз есть такие специализированные средства, как VMware Carbon Black, vRealize Log Insight и vRealize Network Insight, но базовые требования информационной гигиены нужно соблюдать и на уровне гостевых систем.

На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:

• C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe (Windows)
• /usr/bin/vmware-toolbox-cmd (Linux)

Само собой приведенные ниже рекомендации - это руководство для параноиков (но, как говорит Эндрю Гроув - выживают только параноики), потому что безопасность, как вы знаете - это всегда компромисс между удобством и маниакально-призрачным ощущением защищенности.

И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:

1. Отключить синхронизацию времени с хостом VMware ESXi

Время - очень важная категория в контексте безопасности. Оно важно для логов, для синхронизации событий аутентификации и прочего. По-хорошему, гостевая ОС должна получать время от NTP-сервера, а не от ESXi, который может быть скомпрометирован. Если вы сомневаетесь, что у вас настроено иначе, нужно принудительно отключить синхронизацию времени с хостом. Делается это следующей командой:

VMwareToolboxCmd.exe timesync disable

2. Отключить автообновление VMware Tools

Если у вас в компании принято, что рабочий процесс обновления системных компонентов должен быть унифицирован и контролироваться из одной точки, то можно отключить автоапдейт VMware Tools. Делается это так:

VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false

3. Отключить возможность кастомизации ОС при клонировании

Такая опция позволяет изменять параметры виртуальной машины и гостевой системы, что может быть выгодно злоумышленнику. Отключить кастомизацию ВМ можно следующей командой:

VMwareToolboxCmd.exe config set deployPkg enable-customization false

4. Контроль над информацией, предоставляемой через Appinfo

Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:

VMwareToolboxCmd.exe config set appinfo disabled true

5. Отключить Guest Operations (оно же Invoke-VMScript)

Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:

VMwareToolboxCmd.exe config set guestoperations disabled true

6. Отключение ненужных компонентов

Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".

Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.

На днях компания VMware выпустила обновление своего решения для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vRealize Network Insight 5.3. О версии vRNI 5.1, анонсированной на VMworld 2019, мы писали вот тут.

Напомним, что это решение позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Давайте посмотрим, что нового появилось в vRNI 5.3:

1. Новые возможности VMware SD-WAN (бывшие технологии VeloCloud)

Появилась новая диаграмма Flow visibility, показывающая распределение потоков, рождающихся на уровне SD-WAN Edge и дальше уходящих на уровень интернета:

Также можно выставить фильтр на уровне клиентских IP (чтобы видеть трафик конкретных клиентов), а также на уровнях Flow Path, приложения и Destination Edge.

Кроме этого, появилась диаграмма End-to-end путей в разрезе потоков и конфигураций:

Теперь можно визуализовать путь трафика для конкретного потока между конечными точками клиентов (flow based). А еще можно сделать диаграмму и на уровне сетевой конфигурации, которая у вас настроена (config based).

2. Интеграции с NSX-T

В этом плане появились дополнительные возможности по измерению различных типов задержек в сети (latency): vNIC to vNIC, pNIC to vNIC, VTEP to VTEP.

Помимо этого, была добавлена поддержка продуктов NSX-T 3.0 и NSX-T в облаке VMware Cloud on AWS, а также поддержка TCP Retransmission (отслеживание приложений, испытывающих проблемы с повторной передачей TCP-трафика в случае неудачной первой доставки).

Вот тут показаны TCP retransmissions на базе потоков:

3. Улучшение поддержки сетевого оборудования

Была добавлена поддержка устройств HP Enterprise FlexFabric 5940 и FlexNetwork 10500. Также добавили коммутаторы Mellanox серий SN2100 и SN2410.

4. Прочие улучшения

В целом, было сделано множество небольших улучшений и нововведений, вот основные из них:

• Важные сообщения от устройств Arista соотносятся с самим устройством (Port down, проблемы Fan & PSU и другое)
• Метрика Quality of Experience на уровне туннеля для SD-WAN Edge.
• На дэшборде SDDC теперь есть представление VMware Cloud on AWS Direct Connects.
• Security Planner был оптимизирован для больших инсталляций и теперь обрабатывает большие объемы данных корректно.
• Виртуальный модуль Collector теперь может обрабатывать до 35 000 виртуальных машин на одном сервере vCenter.

Скачать VMware vRealize Network Insight 5.3 можно по этой ссылке. Release Notes доступны тут.

Компания VMware недавно выпустила интересную бесплатную книгу "Micro-segmentation for Dummies Guide, 2nd Edition".

Те из вас, кто использует решение для сетевой виртуализации и агрегации трафика VMware NSX и средство обеспечения сетевой безопасности vRealize Network Insight, знают о таком подходе как микросегментация. С помощью него можно управлять сетевыми политиками на базе контекстов приложений - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности).

Данная модель позволяет контролировать сетевой трафик на более гранулярном уровне, чем на уровне виртуальных машин и модулей Virtual Appliance, а также существенно повышает безопасность коммуникаций за счет принципа выдачи наименьших привилегий и фаерволлинга на уровне микросегментов.

Из книжки вы узнаете:

• Как разработать архитектуру защищенного датацентра на базе сетевой виртуализации и фаерволлинга на уровне рабочих нагрузок.
• Как микросегментация позволяет предотвратить распространение скрытых угроз в инфраструктуре датацентра.
• Топ 10 бизнесовых и функциональных преимуществ микросегментации.

Скачать книгу "Micro-segmentation for Dummies Guide, 2nd Edition" можно по этой ссылке.

Осенью 2018 года мы писали об утилите True SSO Diagnostic Utility, с помощью которой можно проводить диагностику сертификатов Horizon View Enrollment Server (ES), настроек Active Directory PKI и свойств служб сертификации Enterprise Certificate Authorities (CA).

На днях же VMware на сайте Labs выпустила еще одно средство - True SSO Configuration Utility, предназначенное уже не только для диагностики, но и настройки сертификатов True SSO для использования с View Connection Server, Enrollment Server и вашим центром сертификации (Certificate Authoriry) и Active Directory.

Для корректной работы утилиты вам понадобятся следующие компоненты инфраструктуры:

• VMware Horizon Connection Server
• VMware Horizon Enrollment Server
• Microsoft Certificate Authority
• Workspace One Access

Чтобы начать использовать True SSO Configuration Utility нужно лишь запустить ее на Horizon Connection Server.

Видео установки и первоначальной настройки можно скачать по этой ссылке, а само средство True SSO Configuration Utility доступно для загрузки здесь.

Оказывается, на ресурсе VMware Techzone есть не только образовательные материалы, но и полезные утилиты, в частности, VMware Digital Workspace Topology Design Tool. С помощью этого средства администратор может выбрать имеющиеся у него компоненты решений VMware Workspace ONE и VMware Horizon, а также указать вариант развертывания - и нарисовать архитектурную диаграмму сетевой инфраструктуры.

Чтобы получить доступ к этой утилите, переходим по данной ссылке и в разделе Architect and Integrate кликаем по ссылке Launch для виджета Digital Workspace Topology Tool:

После этого нас попросят авторизоваться с кредами My VMware или Partner Portal и попросят ввести название профиля:

Далее нужно выбрать компоненты инфраструктуры Workspace ONE, которые будут использоваться для построения архитектуры (то есть те, которые вы планируете развертывать):

Дальше нужно указать уже компоненты инфраструктуры Horizon, для варианта On-Premises нужно выбрать составляющие решения Horizon 7 в инфраструктуре на вашей площадке:

В итоге вы получите результат с архитектурой сетевой инфраструктуры:

Также вы можете отобразить отчет по необходимым для открытия портам сетевых экранов, через которые осуществляется взаимодействие между компонентами:

Также можно и сохранить полученную конфигурацию в своем профиле (иконка с дискетой).

Не так давно мы писали о той функциональности, которой уже нет в VMware vSphere 7, а также о том, какие фичи находятся в состоянии Deprecated. Это значит, что они пока еще есть в текущем релизе, но уже точно будут отсутствовать в следующей версии платформы. Одной из таких фич стала аутентификация Integrated Windows Authentication (IWA), она же "встроенная проверка подлинности Windows".

IWA - это механизм, который позволяет аутентифицироваться через встроенную аутентификацию ОС в сервисах сервера vCenter, который подключен к домену Microsoft Windows Active Directory (AD).

Депрекация этого механизма в vSphere 7 означает, что вы все еще можете смигрировать настройки IWA при апгрейде vCenter, а также развернуть его с нуля. После этого IWA позволит пользователям аутентифицироваться на vCenter.

Почему поддержка IWA уходит из vSphere? Ответ прост - раньше vCenter работал на платформе Windows как приложение для этой ОС с соответствующими возможностями доступа к ее функциям и сервисам AD, теперь же это виртуальный модуль (vCenter Server Appliance), который работает на базе Linux (а точнее Photon OS) и не может быть нативной частью домена.

Какие альтернативные способы можно использовать для аутентификации в домене AD:

• С использованием LDAP. Контроллеры домена предоставляют сервисы LDAP, которые может использовать vCenter.
• С использованием нового механизма Identity Federation (появился в версии vSphere 7). Эту возможность можно применять для соединения vCenter к Active Directory Federation Services (ADFS) с использованием протоколов OAUTH2 и OIDC.

VMware также объясняет, что присоединение vCenter к инфраструктурам, которые зависят от этого vCenter, может потенциально создать проблемы зависимостей: контроллер домена зависит от включенного в него vCenter как виртуальная машина, а vCenter зависит от домена как его член.

Еще одна причина депрекации IWA - "политическая". Некоторые крупные организации имеют очень строгие правила для администраторов по заведению новых систем в домен и обслуживанию его жизненного цикла. Нередка ситуация, когда администраторы vSphere, которые имеют право включать vCenter в домен, получают бан аккаунта от безопасников, которые отключают его за неактивность.

Аналогичный подход к депрекации IWA компания VMware сделала и для серверов ESXi - они будут поддерживать взаимодействие с доменом на тех же условиях, что и vCenter. Правами доступа к хост-серверам ESXi можно управлять через стандартный механизм Role-Based Access Controls (RBAC) на сервере vCenter.

Поэтому по совокупности причин было решено отказаться от IWA в пользу более гибкого механизма LDAP/LDAPS.

Кстати, если вы видите в логе контроллера домена событие Event 2889 при использовании IWA, то обратитесь к статье KB 78644.

Чтобы переключиться на новый способ аутентификации нужно вывести серверы из домена по старой схеме и включить интеграцию по новой. Вот, например, видео о том, как смигрировать аутентификацию с LDAP на более защищенный протокол LDAPS:

Перед переходом всей инфраструктуры на новый способ аутентификации нужно обязательно протестировать сам метод в тестовой инфраструктуре. Ну а когда будете делать перевод продакшена, не забудьте сделать снапшот сервера vCenter - если что на него можно будет откатиться с сохранением старых настроек.